Two different views about software complexity

The aim of this work is to analyse the several metrics used in software engineering to assess the complexity of software products. First we discuss the differences between the complexity of the problem and the complexity of the solution (implementation) setting up several metrics that can be used in measuring both of above aspects. We define what is the difference in complexity between a problem and a solution.. Next we describe the software development process as a series of successive transformations. The first model constructed is the requirements document and the last model is the code, which represents the particular solution. Then we analyse the relation between complexity, effort and efficiency and we will describe some metrics, which can be used to measure them. We notice that conventional software metrics doesn't reflect the all aspects of problem/solution complexity. It is shown that no single metric alone could measure all the complexity aspects of the product. Finally we describe the metrics used in the complexity fields like algorithmic complexity, logical complexity, information theory, Shannon entropy, statistical complexity, grammatical complexity, etc. We compare each one with others and show that the last ones are suitable for measuring the global aspect of complexity in the software problem/solution. We conclude that it is possible to use complexity metrics used in complex systems in software engineering with some advantages. 1. Complexity of the problem and it’s solutions . According to the Many Lehman software process definition,[19] a solution of a problem is an operational model obtained from a set of transformations applied to the initial model of that problem. So behind each solution there is a problem. However the complexity of the problem differs from the complexity of the solution. Complex solutions may exist for simple problems. In this paper we will use the following definitions: [9] [5] [16] [17] [18] [31] The complexity of a problem is the amount of resources required for an optimal solution of the problem . The complexity of a solution is the amount of resources required for that solution of the problem . In order to evaluate the complexity of a solution several types of metrics are frequently used: [9] [5] • Algorithmic Complexity Is required to reflect the algorithmic complexity in each solution. There are two types of metrics in this class: one is the complexity based on the algorithmic efficiency, the other is the complexity on the structure of the algorithm. • Cognitive Complexity Is required to reflect the amount of effort needed to understand the problem. In order to assess problem complexity [8], metrics of Computational Complexity are used. 2. Some Metrics of solution complexity The assessment of effort necessary to implement a product is frequently measured on the algorithm. It may be calculated based on the Algorithmic Efficiency. We measure efficiency in terms of the number of primitive operations required for a given output. Using the “Big O” [9] notation, the algorithm is considered to have a constant complexity when it's efficiency is O(I), logarithmic complexity when it’s efficiency is O(logn), and so on. The reasoning behind this is that the fewer primitive operations are needed the less complex is the algorithm. It can also be calculated based on the structure of the a algorithm. There are tree types of Structural Metrics [30] [5] . • The control flow that adresses the sequence in which instructions are executed in a programme • The data flow that follows the trail of data as it is handled by a programme • The data structure that evaluate the organization of the data itself. To measure control-flow structure complexity of an algorithm, it must be transformed in to a flowgraph [9] [20] [5] [32] . It has been proved that every flow graph has a unique decomposition into a hierarchy of primes. The so-called Hierarchical Metrics are constructed based on that tree. They are: • The number of nodes • The number of edges • The largest prime measure • The d-structured measure One of the best known metrics of this type is the McCabe Cyclomatic Complexity Measure, it is also calculated on the flow graph and represents the number of independent pahts needed to reach each node on the graph. [9] [5] [6] An Essential Complexity metric was also produced by McCabe in order to measure the overall level of the algorithmic structuredness. A more intuitive notion of essential complexity may simply be the cyclomatic number of the largest print in the decomposition tree. Several other metrics were proposed for this type of measurement. Vinap [22] and Knot [23]metrics can be studied under the given references. Another approach used to measure structural complexity is to measure the testing difficulty of the model. Those metrics measure[24] the minimum number of test cases and he test effectiveness ratio. In order to the measure the data flow structure complexity [9] [5] we analysed the relationship between the models of the programme . We worked on the transformation of the design in a call-graph, which represented the modular hierarchy and showed the exchange of information between the modules. Other types of diagrams [9] [5] [25] are used to analyse the exchange of data inside the modules. Metrics of this type are: • Global modularity in which the average module length is calculated. This is based on the reasoning that the shorter are the modules the lesser the complexity . • Tree impurity shows how far a given graph deviates from being a tree. This is based on the reasoning that the more distant is a call graph from a tree the more complex it is. Coupling and Cohesion [9] [5] [26] metrics of the modules can also be used as complexity metrics: designs showing tight coupling and lack of module cohesion are complex. We can also use the total level of information flow through a system and the total level of information flow between individual modules and the rest of the system. As an example: The information flow complexity that uses the lenght , the fan-in and fan-out of the module, whose authors are Henry and Kafura. [9] Based on this method Shepherd [27] developed the Shepherd complexity, which is concentrated solely on the flow information of a module. There is a high correlation between this measure and the development time. The reasoning behind this is that the more complex is a module the longer is the time required for it’s development. Metrics analogous with the algorithmic structure were used to measure data structure complexity [29] [28] .Thus each data type was considered as a primitive and the resulting primitive hierarchy was measured for data structure. 3. Metrics of Problem Complexity To find the optimum solution is the relevant issue in measuring problem complexity. So we must use compression techniques. We compress data in order to use less memory in order to stock it and less time for it’s manipulation. The reasoning behind the compression process consist in finding strings of frequently used characters and substituting them by a shorter code. Problem complexity is defined as the number of bites that can represent a product after compression. 4. Dificulties with complexity software metrics In the field of product and software process the existing individual complexity metrics described in previous sections are not successful. In our opinion the main reasons are: • Metrics are language and form dependent: a different metrics has to be used for different programming languages, different metric for the machine code, object code, etc. Software can be represented in many forms: requirements, specification, documentation, user interfaces, help files, and all that representations can be manifested in very different appearances: written text, graphical, symbolic, formal languages, etc. – again many different (incompatible and incomparable) metrics has to be used to measure all of them. As a consequence we are not able to measure the software in the holistic manner, compare various products, trace complexity trough the design steps, etc. • The output of a traditional complexity metric is a number, usually without any “physical” meaning and unit.(we don’t know what are we measuring), without critical values indicating what is large or small – no fundamental conclusions can be deducted or induced, • The relations metrics ⇔ software are rarely known – thereafter such metrics are a poor basis for stating fundamental laws. So in order to improve the software process we need other types of metrics.